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Title: 

System and Method for Optimizing Revenue and/or Bookings from Collected Demand 
Data in a Buyer-Driven Commerce System. 

Onss-Referenre to Relate d Applications 

This application claims priority under 35 U.S.C. §1 19 to U.S. Provisional Patent 
Application Ser. No. 60/231,145 entitled "SYSTEM AND METHOD FOR OPTIMIZING 
REVENUE AND/OR BOOKINGS FROM COLLECTED DEMAND DATA IN A BUYER- 
DRIVEN COMMERCE SYSTEM" filed in the name of Sunmee Choi on September 8, 2000, 
herein incorporated by reference. 

This application is further related to U.S. Provisional Patent Application Ser. No. 
60/231,456 entitled "SYSTEM AND METHOD FOR MAXIMIZING ACCEPTANCE 
PARAMETERS FROM COLLECTED DEMAND DATA IN A BUYER-DRIVEN 
COMMERCE SYSTEM" filed in the name of Michael Majeed and Sunmee Choi on September 

8, 2000, and U.S. Patent Application Ser. No. entitled "SYSTEM AND METHOD 

FOR MAXIMIZING ACCEPTANCE PARAMETERS FROM COLLECTED DEMAND DATA 
IN A BUYER-DRIVEN COMMERCE SYSTEM" filed in the name of Michael Majeed and 
Sunmee Choi on August 31, 2001, the entirety of each being incorporated herein by reference. 

Field 

The present invention is directed generally to data processing for cost/price 
determination, and more particularly to market analysis and demand forecasting or surveying. 
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Background 

Most systems for processing the sale of products are seller-driven, whereby the seller 
5 prices, packages, configures and offers the product for sale, and the buyer decides whether or not 
to accept the seller's offer. In a buyer-driven commerce system, on the other hand, the buyer 
dictates the terms of the offer and one or more sellers decide whether or not to accept. A "help 
wanted" advertisement, for example, is a buyer-driven inquiry since an employer is looking to 
locate and buy the services of a qualified employee. The inquiry is advertised to a large number 
If of potential employees, who may respond by submitting their resumes to the prospective 
yQ employer. 

J United States Patent No. 5,794,207 entitled "Method And Apparatus For A 

^ Cryptographically Assisted Commercial Network System Designed To Facilitate Buyer-Driven 
yj Conditional Purchase Offers" which is assigned to the assignee of the present invention and 
IS incorporated herein by reference, discloses a buyer-driven Conditional Purchase Offer (CPO) 
*m Management System that processes binding purchase offers received from individual consumers. 
.U The purchase offers contain one or more buyer-defined conditions for the purchase of goods or 
rf services, at a buyer-defined price. The purchase offers are typically guaranteed by a general- 
purpose financial account, such as a debit or credit account, and thereby provide sellers with a 
20 mechanism for enforcing any agreement that may be reached with the consumer. The purchase 
offers are provided by the CPO Management System to sellers, for individual sellers to either 
accept or reject. If a seller accepts a purchase offer, the CPO Management System binds the 
buyer on behalf of the accepting seller, typically by charging the general-purpose financial 
account designated by the buyer or providing the account information to the accepting seller for 
25 processing, to form a legally binding contract. Thus, the CPO Management System empowers 
individual consumers to obtain goods and services, such as travel or insurance services, at prices 
which are set by the consumers. The CPO Management System provides numerous commercial 
advantages to sellers as well For example, the CPO Management System permits individual 
sellers to effectively sell excess capacity when actual demand fails to meet forecasted demand. 
30 In particular, the CPO Management System provides an effective mechanism for sellers to be 
confident that if they accept a consumer's offer, the consumer will purchase the requested goods 
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or services at the agreed-upon price. Yet, the consumer remains unable to use the information to 
ascertain the seller's underlying level of price flexibility, which, if known to a seller's 
competitors or customers, could dramatically impact the seller's overall revenue structure. 

United States Patent No. 6,085,169 entitled "Conditional Purchase Offer Management 
5 System," which issued to the assignee of the present application and is incorporated by reference 
in its entirety herein, discloses a conditional purchase offer (CPO) management system that 
permits sellers to provide proprietary rules for the acceptance of CPOs. Each of these rules 
establishes one or more restrictions which the seller is willing to accept for a predefined 
minimum price. The rules are utilized by the CPO management system to determine whether to 
W accept, reject or counter a CPO on behalf of a particular seller. In this manner, the CPO 
J3 Management System can respond to submitted CPOs in real-time on behalf of sellers, with a 
"p minimal amount of expensive, time consuming and error-prone human intervention. 
W For many transactions, the embodiments of the CPO Management Systems discussed 

|i| above, will effectively complete transactions between buyers and sellers, with minimal 
1=5 intervention by the parties once the CPO has been submitted. The performance of the CPO 
CO Management System depends, at least in part, upon its utilization by a large number of both 

buyers and sellers. Specifically, buyers are more likely to submit purchase offers if they know 
rf the purchase offers will be reviewed by a sufficiently large number of sellers. Likewise, sellers 

are more likely to review offers if a sufficiently large number of offers are submitted. In addition 
20 to being a lost business opportunity, purchase offers which are not accepted represent a waste of 
time and effort by both buyers and sellers. Thus, buyers and sellers alike will be frustrated and 
discouraged from utilizing the CPO Management System if the acceptance rate for submitted 
purchase offers does not meet acceptable levels. 

Invariably, some buyers will submit purchase offers that are not initially accepted by any 
25 seller, typically because the price offered by the buyer is too low In addition, some sellers may 
set their acceptance parameters too high to attract sufficient demand to fulfill all available 
bookings. Also, a system operator of the CPO management system may set operating 
parameters, such as a minimum required margin on a sale, which are incompatible with 
adjustments in purchaser demand. These factors, alone or in combination, may then result in an 
30 inordinate amount of purchase offers being rejected as originally posted. Thus, buyers, sellers 
and system operators of a buyer-driven commerce system, alike, would benefit if a system for 
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analyzing demand data is provided to determine optimum parameters to increase acceptance of 
purchase offers. Such a system, in turn, would provide the means to increase revenue for the 
system operator and for sellers who participate in the buyer-driven commerce system. 

Accordingly, there is a need for a system and method for optimizing revenue and/or 

5 bookings from collected demand data in a buyer-driven commerce system which addresses 

certain shortcomings of existing technologies. 



Summary 

fO The present application is directed to particular features of a system and method for 

y*j optimizing revenue and/or bookings from collected demand data in a buyer-driven commerce 
s system. In particular, one embodiment includes a system and method for optimizing revenue 
P? from a buyer-driven commerce system for hotel reservations, although other applications may be 
Jf; available. The system receives a plurality of purchase offers for a booking from a plurality of 
! 'T5 potential purchasers and compares them to at least one acceptance parameter for the booking 
which may be provided by a seller. Each purchase offer preferably includes demand data, such 
as a customer identifier, a payment identifier, a rating for a hotel, a location for a hotel, a number 
of room nights, an occupancy of the room, a room type and a price. The demand data is then 
stored by the system. The system then receives an input of a simulated change to the acceptance 
20 parameter and calculates a simulated acceptance rate for the plurality of purchase offers based on 
the simulated change and the stored demand data. This information may then be provided to the 
seller in order to determine an optimum value for the acceptance parameter. 

According to a second embodiment, a system and method for determining an optimized 
acceptance rate for purchase offers submitted to a buyer-driven commerce system includes 
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receiving a plurality of available bookings from a seller Each available booking includes 
information such as an acceptance parameter, a date of availability, a room type, and a 
geographic location A plurality of purchase offers are then submitted for the plurality of 
bookings, of which certain of the purchase offers may be rejected. These unaccepted purchase 
5 offers are then stored. The system then determines a number of the unaccepted purchase offers 
which would be accepted based on a change of the acceptance parameter. 

According to a third embodiment, a system and method for determining an optimized 
S acceptance rate for purchase offers submitted to a buyer-driven commerce system includes a 
1 seller providing a plurality of available bookings to the system Each of the bookings preferably 
F$ includes at least one of an acceptance parameter, a date of availability, a room type, and a 
W geographic location. The system then provides to the seller an indication of a plurality of 
5 unacceptable purchase offers submitted for at least one of the available bookings. The system 
H further provides an indication of a number of the unacceptable purchase offers which would be 
5 accepted based on a change of the acceptance parameter. 

1 5 According to a fourth embodiment of the present invention, a system and method for 

optimizing performance of a buyer-driven commerce system includes receiving a number of 
available bookings from a seller. Each of the bookings preferably has an acceptance parameter 
such as a minimum price. Users may then submit a plurality of purchase offers for the available 
bookings. After certain of the purchase offers are rejected, the demand data associated with the 

20 rejected purchase offers is stored. Either the system operator or the seller may then input a 
simulated change of the acceptance parameter and a simulated acceptance rate or the like is 
determined based on the stored demand data and the simulated change. 
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Brief Description of the Drawings 

Further aspects of the instant invention will be more readily appreciated upon review of 
the detailed description of the preferred embodiments included below when taken in conjunction 
5 with the accompanying drawings, of which; 

FIG. 1 is a block diagram of a network in accordance with an embodiment of the present 
invention; 

ft) FIG. 2 is a schematic block diagram of a system server in accordance with an 

^ embodiment of the present invention; 

FIG. 3 is a tabular representation of a demand database in accordance with an 

saw 

^ embodiment of the present invention; 

Ss 

rf FIG. 4 is a tabular representation of a booking database in accordance with an 

embodiment of the present invention; 

FIG. 5 is a flow chart depicting an exemplary booking process according to an 
20 embodiment of the present invention, 

FIG. 6 is a flow chart depicting an exemplary process for determining promotional 
subsidy amounts according to an embodiment of the present invention; 

25 FIGS. 7-8 are a flow chart depicting an exemplary process for calculating margin and 

subsidy amounts according to an embodiment of the present invention; 

FIG. 9 is a flow chart depicting an exemplary process for determining a subsidy amount 
and a bump amount according to an embodiment of the present invention; 
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FIG. 10-1 1 are a flow chart depicting an exemplary process for determining an 
acceptance or failure of a booking according to an embodiment of the present invention; 

FIG. 12 is a flow chart depicting an exemplary process for calculating a subsidy 
according to an embodiment of the present invention; 

FIG 13-14 are flow charts depicting an exemplary process for determining a booking 
with a subsidy amount in accordance with an embodiment of the present invention; 

FIG 15 is an exemplary screen display for entering margin and subsidy amounts in 
accordance with an embodiment of the present invention; 

FIG. 16-22 are exemplary screen displays for receiving simulation outputs according to 
an embodiment of the preset invention; 

FIG. 23 is an exemplary process for determining the number of offers received for a 
particular seller; 

FIG. 24 is a flow chart depicting an exemplary process for determining an average 
booked cost for fulfilled purchase offers according to one embodiment of the present invention; 

FIG. 25 is a flow chart depicting an exemplary process for determining aggregate 
purchase offer data from a plurality of submitted purchase offers according to an embodiment of 
the present invention; 

FIGS. 26-33 are flow charts depicting exemplary processes for generating demand 
reports in accordance with an embodiment of the present invention; 

FIGS. 34-47 are depictions of exemplary demand reports generated from the process of 
FIGS. 28-36 
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Detailed Description 

The systems and methods disclosed herein may be used in conjunction with the features 

of co-pending U.S. Patent Application Ser. No 09/ entitled "System and Method for 

Maximizing acceptance Parameters From Collected Demand Data in a Buyer-Driven Commerce 
System" filed concurrently herewith in the name of Choi et al. and assigned to the assignee of the 
present application, the entirety of which is herein incorporated by reference. 

According to various embodiments of the present invention, a buyer-driven commerce 
system may collect data relating to unfulfilled purchase offers provided by one or more potential 
buyers. The collected data may then be used to simulate how changes in various acceptance 
parameters, such as the system operator's minimum margin amount or minimum cost, will affect 
revenue generated for the system operator or a seller participating in the buyer-driven commerce 
system. The simulated results may be presented in one or more periodic reports to the seller, 
who may then decide to optimize one or more acceptance parameters in order to optimize 
revenues received from the buyer-driven commerce system. 

Referring now to FIGS. 1-47, wherein similar components are referenced in like manner, 
preferred embodiments of a method and system for optimizing revenue and bookings from 
collected demand data in a buyer-driven commerce system are disclosed. 

Turning now to FIG. 1, there is depicted an exemplary computer network 10 through 
which a plurality of users operating user terminals 16 may communicate with one or more buyer- 
driven commerce system servers 12 over network connection 18 to submit purchase offers for 
bookings offered by a seller through one or more seller servers 14 
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Although computer network 10 is preferably an Internet-based network such as the World 
Wide Web, it may be any one or more of a local area network (LAN), a wide-area network 
(WAN), an intranet environment, an extranet environment, a wireless network or any other type 
of computer network, such as those enabled over public switched telephone networks. 
5 User terminals 16 may each be any type of computing device, such as a 

personal computer, a workstation, a network terminal, a hand-held remote access device, a 
personal digital assistant (PDA) or any other device that can accomplish two-way electronic 
*s communication over the network connection 18. Specific functions and operations of user 
jp terminals 16, system server 12, and seller servers 14 are discussed further below. 
HD Turning now to FIG. 2, displayed therein are exemplary components of a computing 

^ device, such as system server 12. It should be understood that any of user terminals 16, and 
seller server 14 may share similar configurations. However, for sake of brevity, the discussion 
immediately below will refer to the system server 12 only. 
Li The primary component of the system server 12 is a processor 20, which may be any 

15 commonly available microprocessor, such as the PENTIUM III manufactured by INTEL CORP. 
The processor 20 may be operatively connected to further exemplary components, such as 
RAM/ROM 22, a clock 24, input/output devices 26, and a memory 28 which, in turn, stores one 
or more computer programs 30, a demand database 32, and a booking database 46. 

The processor 20 operates in conjunction with random access memory and read-only 
20 memory in a manner well known in the art The random-access memory (RAM) portion of 
RAM/ROM 22 may be a suitable number of Single In-line Memory Module (SIMM) chips 
having a storage capacity (typically measured in kilobytes or megabytes) sufficient to store and 
transfer, inter alia, processing instructions utilized by the processor 20 which may be received 
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from the application programs 30. The read-only memory (ROM) portion of RAM/ROM 22 
may be any permanent, non-rewritable memory medium capable of storing and transferring, inter 
alia, processing instructions performed by the processor 20 during a start-up routine of the 
system server 12. 

The clock 24 may be an on-board component of the processor 20 which dictates a clock 
speed (typically measured in MHz) at which the processor 20 performs and synchronizes, inter 
alia, communication between the internal components of the system server 12. 

The input/output device(s) 26 may be one or more commonly known devices used for 
receiving system operator inputs, network data, and the like and transmitting outputs resulting 
therefrom. Accordingly, exemplary input devices may include a keyboard, a mouse, a voice 
recognition unit and the like for receiving system operator inputs. Output devices may include 
any commonly known devices used to present data to a system operator of the system server 12 
or to transmit data over the computer network 10 to remote users 16 and seller server 14. 
Accordingly, suitable output devices may include a display, a printer and a voice synthesizer 
connected to a speaker 

Other input/output devices 30 may include a telephonic or network connection device, 
such as a telephone modem, a cable modem, a T-l connection, a digital subscriber line or a 
network card, for communicating data to and from other computer devices over the computer 
network 10. In an embodiment involving a network server, it is preferred that the 
communications devices used as input/output devices 30 have capacity to handle high bandwidth 
traffic in order to accommodate communications with a large number of user terminal 16 and 
seller server 14. 
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The memory 28 may be an internal or external large capacity device for storing computer 
processing instructions, computer-readable data, and the like. The storage capacity of the 
memory 28 is typically measured in megabytes or gigabytes. Accordingly, the memory 28 may 
be one or more of the following- a floppy disk in conjunction with a floppy disk drive, a hard 
5 disk drive, a CD-ROM disk and reader/writer, a DVD disk and reader/writer, a ZIP disk and a 
ZIP drive of the type manufactured by IOMEGA CORP., and/or any other computer readable 
medium that may be encoded with processing instructions in a read-only or read-write format. 
9 Further functions of and available devices for memory 28 will be apparent. 

The memory 28 preferably stores, inter alia, a plurality of programs 30 which may be any 
§ one or more of an operating system such as WINDOWS 2000 by MICROSOFT CORP, and one 
yj or more application programs, such as a web hosting program and a database management 
P program of the type manufactured by ORACLE, each of which may be necessary to implement 
W the embodiments of the present invention The programs 30 preferably include processing 

instructions for accomplishing communication of buyer- driven commerce data between user 
15 terminals 16, system server 12 and seller server 14, as described herein. Accordingly, the 
programs 30 may include a web hosting application and the like for allowing users to submit 
information, such as purchase offers, to the system server 12, to receive information regarding 
bookings that are available through the system server 12, and the like. The web hosting software 
may include functionality sufficient to read JAVASCRIPT, HTML, XML and other similar 
20 programming languages typically used in conjunction with Internet applications. The programs 
30 preferably also include a database management program, of the type commonly manufactured 
by ORACLE CORP. to save, retrieve and analyze demand data received through system server 
12. The programs 30 also preferably include other applications, such as VISUAL BASIC, to 
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allow a system operator to program specific functions to be performed by the system server 12 as 
described herein. The programs 30 operate to form a buyer-driven commerce system which 
operates in the manner described hereinbelow. 

The memory 28 preferably also stores a plurality of relational databases, such as a 
5 demand database 32 and a booking database 46, examples of which are depicted in FIGS. 3 and 
4. In referring to the databases depicted therein, it is important to note that the first row of the 
databases includes a field header for each field of the database and the remaining rows each 
y correspond to one record of the database Fields of data, are represented by each column. 
£ Further or fewer fields and records of data may be used. The databases presented herein may be 
fo configured into any number of relational databases. In addition, configurations other than 
W database formats may be used to store the data maintained in exemplary databases 32 and 46. 
2 Referring now to FIG. 3, an exemplary demand database 32 is provided to store purchase 

2 offer information and customer data which are submitted to the system server 12 by the plurality 
5 of users through user terminals 16. In a particular embodiment, the demand database 32 stores 
1 5 only the demand data for purchase offers which were submitted to the system 12 and which were 
rejected by the sellers participating in the buyer-driven commerce system. In such an 
embodiment, the exemplary demand database 32 preferably has a customer identification field 
34, a requested dates field 36, an offer price field 38, a requested minimum star rating field 40, a 
participation in promotion field 42 and a resubmitted offer field 44. 
20 The customer identification field 34 preferably contains a unique identifier pertaining to a 

particular user or potential purchaser who accesses the system 12 to place a purchase offer for a 
booking, such as a hotel reservation. The unique identifier may be any alphabetic, numeric or 
alpha-numeric code which is assigned to the user. The code may be generated by the system 12 
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or selected by the user upon accessing the system 12. Additional customer identification data, 
such as a customer name, a customer address, a customer telephone number, and a financial 
account identifier corresponding to a financial account owned by the user may likewise be used. 
Alternatively, such data may be stored in a separate customer database (not shown) and cross- 

5 referenced to the information stored in demand database 32 in any known manner. 

Requested dates field 36 preferably stores the dates which a customer has requested for a 
booking. The dates may correspond to a requested check in date and a requested check out date. 

y Offer price field 38 preferably stores the price at which the user has offered to purchase a 

j? booking. In a preferred embodiment, the price corresponds to a per-day rate for the booking. 

M The offer price may also correspond to the initial offer price without a subsidy, promotion offer, 

yj or bump amount as described further herein. 

2 The requested hotel star rating field 40 preferably stores a ranking of the hotel as 

ft requested by the user. It is contemplated that in an embodiment where the user submits a 
U purchase offer for a hotel reservation, the user must submit a rating for the desired hotel. Such 
15 ratings may be based on a number of stars assigned to the hotel. The star ratings are typically 
assigned on a scale from one to five stars, with one star corresponding to the lowest possible 
rating and five stars corresponding to the highest possible rating. The star ratings may be 
determined by the system operator of the buyer-driven commerce system, provided by the seller, 
or determined from a third party ranking of hotel properties. 
20 The participated in promotion field 42 preferably stores an indication of whether the user 

subscribed to one or more promotions offered through the system 12. In a particular 
embodiment, it is contemplated that a number of third parties may offer to add a predetermined 
amount of money to a user's purchase offer in exchange for user information or the user's 
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agreement to participate in a program offered by the third party. As one example, a credit card 
provider may offer to add $50.00 to the user's submitted purchase price in exchange for the user 
open a credit account with the credit card provider. Accordingly, the participated in promotion 
field 42 may contain an indication of the promotion in which the user participated, the bump 
5 amount provided by the party, or other information corresponding to the promotion. 

Resubmitted offer field 44 preferably contains an indication of whether the stored 
demand data is for a resubmitted purchase offer. In one embodiment of the buyer-driven 
S commerce system, it is contemplated that a user may resubmit a purchase offer if an initial 
1 purchase offer is rejected, for example, based on the submitted offer price. However, in one 
W embodiment of the present invention, it is contemplated that particular resubmitted purchase 
W offers, such as offers rejected because of system error, may not be included in the demand data 
3 used for determining an optimum acceptance parameter. This is so that simulated acceptance 
Iff rates as determined below may more accurately reflect actual demand. Accordingly, the 
S resubmitted offer field 44 may be used by the system 12 to exclude the demand data for such 
15 undesirable resubmitted offers. 

Referring now to Fig. 4, a booking database 46 is provided to store and manage seller 
bookings which are available for the submission of purchase offers by the plurality of users 16 of 
the system 12. In a preferred embodiment, the bookings correspond to hotel reservations which 
are provided by hotel proprietors However, it is contemplated that the bookings may correspond 
20 to other products or services which are preferably suitable for a buyer-driven commerce system, 
such as airline ticket reservations, car rental purchases, automobile purchases, mortgages 
groceries, etc In such embodiments, the fields of booking database 46, as described below, may 
be altered to accommodate suitable data for such products and services. In the preferred 
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embodiment, the booking database 46 includes a seller identification field 48, a star rating field 
50, a geographic location field 52, a room type field 53, a minimum acceptable price field 54, a 
date available field 55, a margin required field 56 and a subsidy available field 58. 

Seller identification field 48 preferably stores unique identifiers for each of a plurality of 

5 sellers participating in the buyer-driven commerce system. The unique identifiers may be any 
alphabetic, numeric or alphanumeric code which may be assigned to each seller by the system 12 
or selected by the sellers. In addition, the seller identifier may contain identification information 

5 corresponding to the seller, such as a seller name, a seller address, a seller telephone number, a 

1 seller contact name, and the like. Alternatively, the seller identifier may be cross-referenced to a 
ffj seller database (not shown) which contains such identification information for each seller. 

US Star rating field 50 preferably stores a rating for the property corresponding to the 

2 booking, as described above with respect to the required hotel star rating field 40 of FIG. 3. 

rT Geographic location field 52 preferably stores an indication of the location in which the 

Z booking is available. Accordingly, geographic location field 52 may include a city, state and 
15 postal code corresponding to the booking. In addition, the geographic location field 52 may 

contain an identifier by which the system 12 may determine the location of the available 

booking. 

Room type field 53 preferably stores an indication of a room type available for the 
booking, e.g. single occupancy, double occupancy, smoking, non-smoking, etc. In alternate 
20 embodiments, the room type field 53 may be substituted with a field appropriate to the booking 
being offered. For example, in a buyer-driven commerce system offering airline tickets, the 
room type field 53 may be substituted with a seat class field or the like. 
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The following fields relate to an acceptance parameter set by the seller. Minimum 
acceptable price field 54 preferably stores a minimum price at which the seller is willing to sell 
the booking. Date available field 55 preferably stores an indication of the dates for which the 
booking is available. 

5 The remaining fields of booking database 46 correspond to acceptance parameters which 

are preferably determined by the system operator of the buyer-driven commerce system. Margin 
required field 56 preferably stores a margin amount required for the system operator to 
^ accommodate a submitted purchase offer. The margin may be expressed in a currency amount, 
p but is preferably expressed as a percentage of a sale of the booking to the user. Subsidy 

available field 58 preferably stores a subsidy amount, expressed as a currency value, which is 
yj available for the booking. Both the margin amount and the available subsidy may be 
5 predetermined by the system operator of the buyer-driven commerce system, and an optimum 
ft value for these parameters may be determined according to the processes described below. 
2 Turning to FIG. 5, there is depicted an exemplary booking process 60 by which the 

1 5 system server 12 receives a purchase offer from a user and notifies the user whether a seller has 
accepted the offer. Booking process 60 begins at step 62 where a user submits a purchase offer 
by entering data in user terminal 16 and transmitting the same to system server 12 over network 
connection 18. The system server 12 is programmed to first determine whether the offer meets 
initial acceptability criteria, such as a requirement that valid data be entered, that the submitted 
20 offer price is not obviously low, that check-in and check-out dates have been specified, that the 
submitted offer is not a duplicate offer, etc. If the initial acceptability criteria have been 
satisfied, the process 60 continues to step 68 below. Otherwise the process 60 continues to step 
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66 where the user is notified that the initial acceptability criteria have not been met and the 
system 12 requests the resubmission of valid data. 

Next, the system server 12 may retrieve margin, subsidy, subsidy cap and bump data that 
may be applied to the purchase offer (step 68) In a particular embodiment, it is contemplated 
5 that a purchase offer may be subsidized by the system operator of the system server 12 so that a 
higher purchase offer acceptance rate is achieved, thereby increasing consumer confidence in the 
buyer-driven commerce system. The system operator may then predetermine a subsidy amount 
5 which may be applied to each submitted purchase offer. According to a preferred embodiment 
% of the present invention, an optimal subsidy amount may be determined based on collected 
flj demand data and a subsidy budget maintained by the system operator, as described further 
W below. The system 12 may further determine whether the subsidy budget has been depleted 
2 through application to previously submitted purchase offers, and if so, may not apply a subsidy 
S amount to the newly submitted purchase offer. The system 1 2 may further determine whether 
Z the user has enrolled in a cross-subsidy promotion such that a bump amount will be applied to 
15 the purchase offer. 

Using this information, the system server 12 next determines an adjusted offer price 
which includes a subsidy amount or a bump amount to be applied (step 70). Using the adjusted 
offer price, the system server 12 then compares the submitted purchase offer, including the 
adjusted price, requested star rating, requested geographic location and the like to the plurality of 
20 bookings available in the booking database 46. If one or more matching bookings are found, the 
process 60 continues to step 76 below. Otherwise, the process 60 proceeds to step 74 where the 
user is informed that the submitted purchase offer is not accepted. The notification may be 
provided to the user via a message on the web site. Alternatively, or in addition, the notification 
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may be accomplished via e-mail, telephone, instant messenger service, pager service, or through 
any other similar method of communication. After such notification has been provided, the 
process 60 may end. 

At step 76, the system server 12 next ranks the matching properties, preferably by 
5 comparing the star ratings of the booking, the minimum acceptable price, and the like. The 

system server 12 applies any available margin to the submitted purchase offer price (step 78) and 
searches the ranked bookings (step 80) to determine any bookings which match the data 
submitted with the purchase offer (step 82). If no bookings are matched to the purchase offer, 

1 the system server 12 notifies the user (step 84) Otherwise, the process 60 continues to step 86 
l5 where the system server 12 determines whether the minimum acceptable price for the booking is 
W less than the adjusted offer price (e.g., the offer price less the margin amount). If so, the booking 

2 is completed and confirmed (step 88) after which the process 60 continues to step 98 below. 
2 Otherwise, the process 60 continues to step 90 where the system server 12 determines whether 
2 there are any other available bookings with an acceptable minimum price. If so, the process 

15 returns to step 86 above. Otherwise the process 60 continues as follows. 

Next, at step 92, the system server 12 preferably orders all matching rates in ascending 
order for all matching bookings. The system server 12 then determines if the first ranked rate is 
less than or equal to the adjusted offer price (step 94). If not, the process 60 continues to step 96 
where the system server 12 notifies the user that no bookings are available. If, however, the first 
20 ranked rate matches the adjusted offer price, the process returns to step 88 above. 

After a booking has been confirmed, the process 60 continues to step 98 where the 
system server determines if the purchase offer included a request for more than one room. If no 
further rooms were requested, the process 60 ends at step 100. Otherwise, the process 60 



647644 vl 



19 



PATENT 
3553-4091US1 

continues to step 102 where the system server 12 determines whether there are additional rooms 
available at the same location for the same rate. If so, the process 60 returns to step 88 above. 
Otherwise the process 60 continues to step 104 where the system server 12 determines whether 
there are any other qualifying rates available at the same location. If another qualifying rate is 
found, the process 60 returns to step 88 above. Otherwise, the process 60 continues to step 106 
where the previous booking is cancelled since the number of rooms requested by the customer 
can not be satisfied by the seller at that location. 

The system server 12 then determines whether there is another available booking with a 
qualifying rate (step 108). If so, the process 60 returns to step 88 above where the booking is 
made and confirmed Otherwise, the process 60 continues to step 110 where the system server 12 
determines whether the available bookings remain in ascending order. If they are not in 
ascending order, the process 60 returns to step 92 above However, if the rates are still in 
ascending order, the system server determines that there are no available bookings and notifies 
the user at step 112, after which process 60 ends. 

System Revenue Optimization 

Continuing to FIGS. 6-14, a first simulation program from the plurality of programs 30 is 
provided for determining optimum acceptance values for a system operator of a buyer driven 
commerce system. The second program from the plurality of programs 30 is used to determine 
optimum margin and subsidy amounts to be applied to purchase offers by the system operator. 

Referring first to FIG 6, there is depicted an exemplary process 141 for determining 
promotional bump amounts that may be applied to a purchase offer. The process 141 begins at 
step 142 where the system determines whether a promotion applies to a particular offer. The 
determination may be based upon whether the user submitting the offer has participated in a 
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cross subsidy program or the like. The promotion may include an offer of a currency value to be 
provided to a participant of the promotional offer. If such a promotional bump amount is 
available, the process 141 continues to step 144 as follows. Otherwise the process continues to 
step 152 below. 

5 At step 144, the system server 12 may determine the bump amount to be applied and 

stores the value in demand database 32. The system server 12 then determines the margin and 
the subsidy to be applied to the purchase offer price without the bump amount and stores this 
^ values as well (step 146). Next, the system server determines which is greater, the purchase 
p offer price plus the bump amount, or the purchase offer price with the subsidy (step 148). The 
li greater of the two values is then stored as the final purchase offer price for the submitted 
y purchase offer (step 1 50), after which the process 141 ends. 

O At step 152, the system server 12 determines the final purchase price including a margin 

H? and a subsidy to be applied to the purchase offer price. The final purchase offer price is then 
2 stored (step 154) and preferably marked as ready for comparison to the plurality of bookings 
15 (step 156), after which, process 141 ends. 

Turning now to FIGS. 7-9, therein is depicted an exemplary process 160 for calculating 
margin and subsidy amounts for purchase offers submitted within a predetermined period of time 
according to an embodiment of the present invention. The process 160 begins at step 162 
wherein a subsidy calculation type is selected by the system server 12. If the subsidy type 
20 corresponds to the hotel minimum star rating, the process 160 continues to step 168 below. 

Otherwise, the process 160 continues to step 166 where the star rating is assigned by the system 
operator of the buyer-driven commerce system. From step 166, the process continues to step 170 
below. 
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At step 168, the star rating to be used is set to the star rating assigned to a booking. The 
process then continues to step 170 wherein a margin amount for the selected star rating is 
determined. Continuing to step 172, the system server determines whether the margin type is for 
a currency amount or a percentage value If a percentage is required, the process 160 continues 
5 to step 174 wherein the determined margin amount is calculated as percentage required for the 
submitted purchase offer, after which the process continues to step 178 below. If, however, a 
currency amount is desired, the process continues to step 176 wherein the margin amount is 
l i determined according to the formula- margin amount = offer price*(margin/100). 
S Continuing to step 178, a subsidy amount is determined in the same manner. At step 180, 

S the system server 12 determines whether the subsidy type is to be expressed as a currency 
W amount or a percentage value. If a percentage is required, the process 1 60 continues to step 1 82 
9 wherein the determined subsidy is calculated as percentage required for the submitted purchase 
S offer, after which the process continues to step 186 below. If, however, a currency amount is 
|J desired, the process continues to step 1 84 wherein the subsidy amount is determined according to 
15 the formula: subsidy amount = offer price*(subsidy/100). 

Next, at step 186, the system server 12 determines a subsidy availability for each of the 
purchase offers. The system server 12 then determines whether the subsidy cap will be exceeded 
by calculating the subsidy amount times the number of bookings made within the predetermined 
time (step 188). If the subsidy cap would be exceeded, the process continues to step 200 where 
20 the subsidy amount to be applied is determined as the subsidy cap divided by the number of 
room nights booked for the predetermined time. Otherwise, the final subsidy amount to be 
applied is set to the selected subsidy amount (step 190). 
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From either step 190 or step 200, the process 160 continues to step 202 where the system 
server 12 determines whether a subsidy is available for a particular purchase offer by comparing 
the subsidy amount to an amount of revenue set aside for the subsidy program by the system 
operator of the buyer-driven commerce system. If a currency value is available, the process 69 
5 continues to step 204 where the subsidy amount available is set to the determined subsidy value. 
If no currency value is available, the subsidy amount for a particular purchase offer is set to zerO 
(step 206), after which the process 160 continues to step 208. 
O At step 208, a promotional bump amount is retrieved for a particular purchase offer. At 

TS step 210, the system server 12 determines whether the bump amount is greater than zero. If so, 
III the process 160 continues to step 212. Otherwise, the process 160 continues to step 218 below, 
y At step 212, the system server 12 determines whether the bump amount times the number 

O of rooms requested in the purchase offer times the number of room nights is greater than a 
*fj promotional cap amount. If not, the bump amount applied is equal to the initial bump amount 
™ (step 214). Otherwise, the bump amount is calculated as the cap amount over the number of 
1 5 rooms reserved times the number of room nights requested (step 216). 

From either step 214 or 216, the process 160 continues to step 218 wherein the previous 
subsidy and margin calculation is retrieved. At step 220, the system server 12 determines 
whether the subsidy amount less the margin amount is greater than the bump amount. If so, the 
bump amount is set to zero at step 224. If not, the subsidy amount is set to zero at step 222. 
20 From either step 222 or step 224, the subsidy amount and bump amount for the purchase 

offer is stored in command database 32 (step 226). 

Referring now to FIG 10, there is depicted a process 250 for fulfilling a purchase offer 
based on margin. The process 250 begins at step 252 wherein booking data is retrieved from 
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booking database 46. At step 254, the minimum acceptable rate for each booking is retrieved. 
The rates are then sorted in ascending order (step 256). At step 258, the system server 12 
confirms that booking is available for the buyer driven commerce system. If not, the process 
250 continues to step 260 where the next property location matching a purchase offer is selected. 
5 If other properties are available, the process 250 returns to step 252 above. Otherwise, the 
process 250 ends. 

If, however, the booking is available, the process 250 continues to step 262 wherein the 
^ system server 12 determines whether the submitted offer price satisfies the system operator's 
2 minimum required margin. A process for accomplishing this step is presented below with 
|t| respect to FIG. 1 L At step 264, if the purchase offer can be fulfilled as submitted, the system 
l£ server notifies the user of a successful booking for the submitted purchase offer, after which 
;f process 250 ends. Otherwise, the process 250 returns to step 260 above. 

7: Turning now to FIG. 1 1, a process 270 for determining an acceptance of a booking based 

IJl on margin is presented. The process 270 commences at step 272 wherein the submitted offer 
15 price is compared to the cost of the room for the system operator. At step 274, the system server 
12 determines whether the margin derived from the booking meets a minimum margin amount 
by comparing the available rate to a target rate. If the minimum margin amount is not satisfied, 
the process 270 continues to step 280, where it is determined whether other room rates are 
available for the submitted purchase offer. If so, the process 270 then returns to step 274 above. 
20 Otherwise, the process 270 ends. 

If the margin amount is satisfied, the process 270 continues to step 276 wherein a request 
to book the reservation for the user is submitted. At step 278, the system server 12 determines 
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whether the booking is confirmed. If, so, the customer is notified and process 270 ends. 

Otherwise, the process 270 returns to step 280 above. 

A process 300 for determining a subsidy amount to be applied to a purchase offer is 

depicted in FIG. 12 Process 300 begins at step 302 where it is determined whether a bump 
5 amount is available for the purchase offer. If so, a subsidy amount for the offer is determined as 

the bump amount plus the required margin amount (step 304). Otherwise, the subsidy amount is 

set as the subsidy amount available for the requested star booking (step 306). 
Q Next, at step 308, a target cost for fulfilling the purchase offer is determined as the offer 

'ji price minus the margin required. Then a maximum subsidy cost is calculated as the target cost 
l|| plus the subsidy amount (step 310). 

fjj Then, at step 3 12, the cost of the booking to the system operator of the buyer driven 

O commerce system is retrieved. At step 314, the system server 12 determines whether the target 
W cost calculated in step 308 is less than the room cost from step 312. If so, the process 300 
H continues to step 316. Otherwise, the process 300 continues to step 318 below. 
15 At step 316, the system server 12 determines whether there are other available room rates 

for the selected hotel. If so, the process 300 returns to step 312 above. Otherwise, the system 
server 12 determines whether there are other suitable hotels available for the purchase offer (step 
320). If other hotels are available, the process returns to step 302 above. Otherwise, the process 
300 continues to step 322 where a subsidy list for all previous bookings is resorted in ascending 
20 order, after which process 300 ends. 

Continuing from step 318, the system server 12 determines whether the room cost is 
greater than the maximum available subsidy cost. If so, the process returns to step 320 above. 
Otherwise the process 300 continues to step 324 where the subsidy to be applied is set to the 
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room cost less the target room cost. The process 300 then continues to step 326 where the 
subsidy is added to the list of purchase offers for which a subsidy was applied, after which 
process 300 ends. 

Turning now to FIG. 13, there is depicted an exemplary process 350 for determining a 
booking with a subsidy according to an embodiment of the present invention. The process 350 
begins at step 352 where room rates for a hotel assigned a particular subsidy is retrieved. The 
rates are sorted in ascending order (step 354) At step 356, the system server 12 determines 
whether any of the rates are available to the buyer-driven commerce system. If so, the process 
continues to step 358. Otherwise the process 350 ends. 

At step 358, a request to fulfill a purchase offer including the subsidy amount is 
transmitted by the system server 12 to the seller corresponding to the booking. Then, at step 360, 
the system server 12 determines whether the request was fulfilled. If so, the user is notified of 
the fulfillment of the purchase offer and process 350 ends. If the booking is not successful, the 
process 350 continues to step 362 wherein the system server 12 determines whether there are 
additional subsidies available. If so, the process 350 returns to step 352 above for the new 
subsidy. Otherwise, the user is notified that a booking was not successful. 

A second process 400 for determining a booking with a subsidy is presented in FIG. 16. 
The process 400 begins at step 402 wherein a target cost is calculated for a purchase offer. The 
target cost is preferably calculated as the submitted offer price less the required margin amount. 
At step 404, the system server 12 then calculates the maximum cost for the booking as the target 

cost plus an available subsidy. 

Next, at step 406, the system server 12 determines whether the room cost is greater than 
the target cost. If so, the process 400 continues to step 410 below. Otherwise the process 400 
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continues to step 408 wherein the system server 12 determines whether additional room rates for 
the hotel are available. If so, the process returns to step 406 above for the new room cost. 
Otherwise the process 400 ends. 

At step 410, the system server 12 determines whether the room cost is greater than the 

5 maximum cost calculated in step 404. If so, the process 400 ends. Otherwise, the process 400 
continues to step 412, where the system server 12 requests that the booking be processed by the 
seller. If the booking is successful at step 414, the user is notified that the purchase offer has 

^ been fulfilled. Otherwise, the process 400 returns to step 408 above. 

£ Referring now to FIGS. 15-22, exemplary screen displays corresponding to the second 

f O program from the plurality of programs 30 are depicted. In FIG. 15, an exemplary initial screen 
W 500 includes a number of fields 501 for entering a predetermined time period to simulate 
if acceptance rate based on simulated acceptance parameters. Location 502 allows a system 
£: operator to enter parameter changes for the margin amounts, margin percentage, subsidy 
pL amounts, subsidy percentage and a subsidy cap amount available. The location 502 further 
15 allows a system operator to select a desired simulation output, such as the overall results of the 
change, the results by star rating, the change in the top 25 market performers and the top 10 
hotels that with the biggest change in revenue or acceptances. 

FIG. 16 depicts an exemplary output menu 510 by which a system operator may select 
the category of simulation outputs to view. If the system operator requests an overall output, an 
20 overall output screen 520 may be provided in order to present the overall acceptance statistics to 
the system operator. FIG. 17 depicts an overall output screen 520 with the resulting statistics 
from a simulation. FIG. 17 further includes a output by requested star rating screen 540 which is 
presented when the system operator requests simulation results presented by star rating. 
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If the system operator requests a simulation by booked star rating, the system server may 
present an output screen 550 as presented in FIG. 18. If the system operator requests to see the 
simulation results by the top 25 market performers, the display screen 560 of FIG. 18 may be 
presented. If the system operator requests a report of the top ten hotels with the most business 
5 increase or decrease based on the simulation, the display screen 570 of FIG. 19 may be 
presented. 

A further exemplary screen display 580 is presented in FIG. 20, by which a system 
D operator may input actual and simulation parameter values at location 590 and be presented with 
* the simulation results at location 600. FIGS. 21 and 22 further present exemplary output screens 
ll 610 and 620 corresponding to output by booked star rating and output by requested star rating, 
y respectively. 

W Seller Revenue Optimization 

P A second simulation program from the plurality of programs 30 may be used according to 

15 the present invention, and in conjunction with the system optimization program described above, 
to determine a maximum revenue that can be generated per available room in the buyer-driven 
commerce system. The third program preferably includes a process 700 for determining the 
number of offers received for a particular seller as depicted in FIG. 23. The process 700 begins 
at step 710 where the system server 12 retrieves a plurality of stored purchase offers and the final 
20 status of the purchase offer (e.g. accepted or rejected) for a particular hotel property. At step 
712, the system server 12 determines all the properties which were considered for the retrieved 
purchase offers. Next, at step 714, the system server 12 determines whether each of the offers 
were rejected. If a purchase offer was rejected, the process continues to step 718 below. 
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Otherwise the process 700 continues to step 716 wherein the server selects properties whose 
rating is higher than the property at which the offer was booked. The process then continues to 
step 720 below. 

At step 718, the server selects all the properties that were ranked for the submitted 
5 purchase offer From either step 7 1 6 or 720, the process 700 continues to step 720 wherein the 

system server 12 determines the hotel rate type and the minimum room cost for each selected 

property, after which process 700 ends. 
9 A second process 750 is provided to determine an average booked cost for the plurality of 

f submitted purchase offers. The process 750 begins at step 752 where a total room cost is 
M determined for each offer. The average booked cost is then determined at step 754 by dividing 
3 the total room cost by the number of rooms requested by each purchase offer. This value is then 
5 stored and process 750 ends. 

W FIG. 25 presents an exemplary process 760 for determining hotel statistical data from a 

y plurality of submitted purchase offers is presented. The process 760 begins at step 762 where the 
1 5 offer date for each submitted purchase offer are collected. The requested check-in dates are then 
determined for each submitted purchase offer (step 764). The property type corresponding to 
each purchase offer is then determined (step 766). The status of each purchase offer is then 
determined (step 768). 

From this data, the system server 12 then calculates and stores the following information 
20 for each property considered for each purchase offer: (1) revenue generated for the system 

operator from the plurality of purchase offers, (2) revenue generated for each seller, (3) check in 
date requested, (4) number of room nights requested, (5) rejection code (if any), (6) offer 
accepted by another seller, (7) offer accepted by another seller in same geographic location, (8) 
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minimum star rating requested, (9) bump amount applied, and (10) final offer price including 
bump amount. After this data is determined, the process 760 ends. 

Turning now to FIGS. 26-27, the second simulation program from the plurality of 
programs 30 includes a process 800 for determining aggregate purchase offer data from a 
plurality of submitted purchase offers. The process 800 begins at step 802 wherein the total 
room nights, revenue generated and total length of stay is calculated for each accepted purchase 
offer. The system server 12 then determines the total room nights, revenue and length of stay 
when the requested stay date is the arrival date (step 804). The system server 12 then determines 
the total room nights, revenue and length of stay when the purchase offer is accepted by another 
seller (step 806). The system server 12 next calculates a total number of room nights, revenue 
and length of stay when the requested stay date is the arrival date (step 808). 

The system server 12 next calculates the declined total room nights, revenue and length 
of stay for each property (step 810). The system server 12 then calculates the declined total 
room nights, revenue and length of stay for each property when the stay date is the requested 
arrival date (step 812). 

The system server 12 then determines the lowest room cost rate for each purchase offer 
(step 814). The system then determines the number of room nights and revenue lost due to the 
room cost being too high (step 816) 

Referring now to FIG. 27, the process 800 continues at step 818 where the system server 
12 determines the declined total room nights and revenue due to there being no bookings 
available for the predetermined time period (e.g. the hotel was full during the time period). The 
system server 12 then determines the declined total number of room nights and lost revenue due 
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to bookings not being available for the system operator of the buyer-driven commerce system 
(step 820). 

The system server 12 then determines the total room nights, revenue and length of stay 
lost to other properties within the same geographic location (step 821). The system server 12 
5 then determines the total number of room nights, revenue and length of stay lost to other 
properties within the same geographic location when the requested stay date is the arrival date 
(step 822). 

O At step 824, the system server determines an appropriate rate guide, or values for 

% acceptance parameters, that a seller should consider adopting based on the stored demand data. 

]{§ The process for determining the rate guide is discussed further below with respect to FIG. 30. 

iy At step 826, the system server 12 determines an appropriate rate guide where the price to 

0 the system operator is too high. The process for determining this rate guide is discussed further 

ff below with respect to FIG. 28. 

At step 828, the system server 12 determines an appropriate rate guide where a booking 

15 was not available for the buyer-driven commerce system The process for determining this rate 
guide is discussed further below with respect to FIG. 29. 

Finally, at step 830, the system server 12 determines a daily, weekly, and monthly rate 
decline adjustment. The process for determining these adjustments are discussed further below 
with respect to FIGS. 30-33. 

20 Referring now to FIG. 28, a process 900 is presented for determining a preview rate 

guide where the room cost to the system operator is too high. The process 900 begins at step 902 
where an offer identifier, a total number of room nights, a total revenue, an offer price and 
check-in/check-out dates are retrieved from the demand database 32. For each offer, and for 
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each hotel property, the following steps are iteratively repeated. At step 904, the system server 
12 determines if the percentage of declined offers corresponding to the hotel property is greater 
than or equal to 80% of the total offers which match the property (referred to heerinafter as "total 
offer percentage"). If not, the process continues to step 910 below. Otherwise, the process 
5 continues to step 906 where the offer price is reduced 20%. Then the total number of room 
nights at the reduced offer is calculated (step 908) and provided in a report to the seller, such as 
that provided in FIGS. 41 and 43 discussed below. 
O At step 910, the system server 12 determines if the total offer percentage is at least 60%. 

® If not, the process continues to step 916 below. Otherwise, the process continues to step 912 
(§ where the offer price is reduced 40%. Then the total number of room nights at the reduced offer 
2 is calculated (step 914) and provided in a report to the seller, such as the report provided in FIG. 
O 41 and 43. 

W At step 916, the system server 12 determines if the total offer percentage is at least 40%. 

rf If not, the process continues to step 922 below. Otherwise, the process continues to step 918 
15 where the offer price is reduced 60%. Then the total number of room nights at the reduced offer 

is calculated (step 920) and provided in a report to the seller, such as that provided in FIGS. 41 

and 43. 

At step 922, the system server 12 determines if the total offer percentage is at least 20%. 
If not, the process continues to the next hotel property. Otherwise, the process continues to step 
20 924 where the offer price is reduced 80% Then the total number of room nights at the reduced 
offer is calculated (step 926) and provided in a report to the seller. After each offer and each 
hotel have been analyzed, the process 900 ends. 
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Referring now to FIG. 29, a process 950 is presented for determining a review rate guide 
where no booking is available. Steps 952 to 976 of process 950 correspond directly to steps 902- 
926 of process 900 described above with respect to FIG. 28. A report corresponding to that 
presented in FIGS. 42 and 43 may then be generated from this process 950 
5 Referring now to FIG. 30, an exemplary process 1000 is presented for determining a 

monthly rate adjust based on stored demand data. The process 100 begins at step 1002, where the 
system server 12 determines an offer price and a length of stay requested where the purchase 

0 offers are rejected as being too low in offered price. The system server then retrieves the 
^ maximum highest declined available (HDA) rate for the month which corresponds to the 
flS maximum room rate charged by the hotel owner to the system operator (step 1004). The 

1 rt; 

y following steps are then performed iteratively for each property and each month at the maximum 
O HDA rate: 

W At step 1006, for a particular offer, the system server 12 determines whether the offer 

P price is at least 80% of the HDA. If so, the process continues to step 1008 where the number of 
15 room nights that would be booked at 80% of the HDA rate is determined for presentation in a 

report such as that displayed in FIG 47. Otherwise, the process continues to step 1010. 

At step 1010, the system server determines whether the offer price is at least 60% of the 

HDA. If so, the process continues to step 1012 where the number of room nights that would be 

booked at 60% of HDA is determined. This number may be used to generate a report to the hotel 
20 operator, such as that presented in FIG 47 Otherwise, the process continues to step 1014. 

At step 1014, the system server determines whether the offer price is at least 40% of the 

HDA, If so, the process continues to step 1008 where the number of room nights that would be 
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booked at 40% of the HDA rate is determined for presentation in a report such as that displayed 

in FIG 47. Otherwise, the process continues to step 1018. 

At step 1018, the system server determines whether the offer price is at least 20% of the 

HDA. If so, the process continues to step 1008 where the number of room nights that would be 
5 booked at 20% of the HDA rate is determined for presentation in a report such as that displayed 

in FIG 47 and the process 1000 iteratively repeats as described above. 

Turning now to FIG. 31, therein is depicted an exemplary process 1050 for determining a 

weekly rate adjustment based on stored demand data. Steps 1052 through 1070 correspond 
IS directly to steps 1002 through 1020 of FIG. 30 except that the purchase offer data is for a 
% predetermined week in which demand data was collected. The report generated from process 
yj 1050 may correspond to the report shown in FIG. 46. 

O Turning now to FIG. 32, therein is depicted an exemplary process 1 100 for determining a 

pf daily rate adjustment based on stored demand data. Steps 1 102 through 1 1 120 correspond 
2 directly to steps 1002 through 1020 of FIG. 33 except that the purchase offer data is retrieved 
1 5 only for a predetermined day in which demand data was collected. A report, such as that 

Referring now to FIG. 33, therein is depicted an exemplary process 1 150 for determining 
a weekly arrival rate adjustment based on stored demand data. Steps 1 1 52 through 1 170 
correspond directly to steps 1002 through 1020 of FIG. 30 except that the purchase offer data is 
for purchase offers received which correspond to a request to stay a predetermined week. Data 
20 from this process 1 150 may be used to generate a report, such as that presented in FIGS. 38 and 
39. 

FIGS. 34-47 depict a plurality of reports which may be generated from the second 
simulation program from the plurality of programs 30 which includes the processes described 



647644 vl 



34 



PATENT 
3553-4091US1 

above. The reports include a daily demand report 1200 as depicted in FIGS. 34-37, a weekly 
demand report 1 300 as depicted in FIGS. 38-39, a weekly business trend report 1400 as depicted 
in FIG. 40, a monthly business trend report 1500 as depicted in FIG. 41, a monthly business 
report 1600 as depicted in FIGS. 42 and 43, a monthly detailed booking review 1800 as depicted 
in FIGS. 44 and 45, a weekly reservation request report 1900 as depicted in FIG. 46 and monthly 
reservation request report 2000 as depicted in FIG. 47. Each of these reports may be presented 
to sellers participating in the buyer-driven commerce system. The reports indicate market 
demand trends as well as presenting reports of revenues or bookings lost due to poorly-selected 
acceptance parameters. The reports further present information as to how much revenue and 
bookings may be anticipated based on simulated changes to these acceptance parameters. In this 
manner, a seller participating in the buyer-driven commerce system may increase revenues and 
bookings by reviewing the simulated data and adjusting their acceptance parameters accordingly. 

Although the invention has been described in detail in the foregoing embodiments, it is to 
be understood that the descriptions have been provided for purposes of illustration only and that 
other variations both in form and detail can be made thereupon by those skilled in the art without 
departing from the spirit and scope of the invention, which is defined solely by the appended 
claims. 
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